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ABSTRACT 

Software Defined Networking (SDN) is a promising approach 
for improving the performance and manageability of future 
network architectures. However, little work has gone into 
using SDN to improve the performance and manageability 
of existing networks without requiring a major overhaul of 
the existing network infrastructure. 

In this paper, we show how we can dramatically improve, 
or supercharge, the performance of existing IP routers by 
combining them with SDN-enabled equipment in a novel 
way. More particularly, our supercharged solution substan¬ 
tially reduces the convergence time of an IP router upon link 
or node failure without inducing any reconfiguration of the 
IP router itself. Our key insight is to use the SDN controller 
to precompute backup forwarding entries and immediately 
activate them upon failure, enabling almost immediate data- 
plane recovery, while letting the router converge at its typical 
slow pace. By boosting existing equipment’s performance, 
we not only increase their lifetime but also provide new in¬ 
centives for network operators to kickstart SDN deployment. 

We implemented a fully functional “supercharger” and 
use it to boost the convergence performance of a Cisco Nexus 
7k router. Using a FPGA-based traffic generator, we show 
that our supercharged router systematically converges within 
~ 150ms, a 900 x reduction with respect to its normal conver¬ 
gence time under similar conditions. 

1. INTRODUCTION 

By enabling logically-centralized and direct control of 
a network forwarding plane, Software-Defined Network¬ 
ing (SDN) holds great promises in terms of improving 
network management and performance, while lowering 
costs at the same time. Realizing this vision is challeng¬ 
ing though as SDN requires major changes to a network 
architecture before the benefits can be realized . This 
is problematic as existing networks tend to have a huge 
installed base of devices, management tools, and human 
operators that are not familiar with SDN, leading to sig¬ 
nificant deployment hurdles. As a result, the number 
of SDN deployments has been rather limited in scope; 
there have been efforts in private backbones Hi and 
software deployments at the network edge [^. 


In order to kickstart a wide-scale SDN deployment, 
we argue that operators need to be offered with SDN- 
based technologies possessing at least three key charac¬ 
teristics. First, the advantages of SDN should be readily 
apparent with only a small deployment. Ideally, benefits 
should be reaped with the deployment of a single SDN 
device; as comfort and enthusiasm increases, new SDN 
devices can be incrementally deployed. Second, they 
should be low-risk. In particular, they should require 
minimum changes to existing operational practices and 
should be compatible with currently deployed technolo¬ 
gies. Finally, they should offer a high return, meaning 
the SDN-based technologies should solve a timely prob¬ 
lem. 

As an example of such a technology, we show how 
we can significantly improve the performance of exist¬ 
ing IP routers, i.e. “supercharge” them, by combin¬ 
ing them with SDN-enabled devices. Supercharging a 
router is a low-risk, high-reward operation. First, it 
provides operators with a strong incentives to deploy 
SDN-enabled device as they enable them to increase 
the lifetime of their routers, at a considerably lower 
cost than buying new one^ Second, supercharging a 
router does not change the existing router’s behavior, 
just its performance. Consequently, network operators 
can conveniently troubleshoot and maintain the original 
network. Third, once enough routers have been super¬ 
charged, those deployed SDN equipments can be used 
to implement a more disruptive SDN architecture. 

In this short paper, we supercharge one particular 
aspect of the router performance: its convergence time 
after a link or a node failure. Current routers are often 
slow to converge after a link failure because of the time 
it takes to update their forwarding tables; this is an 
entry-by-entry process that can go on for potentially 
hundreds thousand of entries. Our key insight is that, 
by coupling together a router and a SDN switch, we 
can build a 2-stage forwarding table which spans across 
the two devices with a first lookup done in the router 
and the second one in the switch. With this type of 


^Current SDN switches are orders of magnitude cheaper 
than fully equipped routers. 
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Figure 1: In a classical router, the Forwarding Informa¬ 
tion Base (FIB) is flat, meaning each entry points to 
the actual physical L2 NH. Upon a failure of i?2, ev¬ 
ery single entry (512k) has to be updated to restore full 
connectivity, a time-consuming operation. 
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hierarchical FIB, one can speed up the convergence by 
tagging entries with the same primary and backup Next- 
Hop (NH) in the first table, and then actually direct the 
traffic to the primary or backup NH in the second table. 
This way, if the primary NH fails, only the few entries 
on the switch have to be updated. One contribution of 
our work is to show how we can provision those tagging 
entries in a router using only a vanilla routing protocol. 

Besides convergence, several other aspects of a router 
performance can be “supercharged” by having a 2-stage 
forwarding table. Among others, the size of the router 
forwarding tables can be increased using a SDN switch 
as a cache (similarly to [^). In this case, the router ta¬ 
ble would contain aggregated entries that would get re¬ 
solved in the switch table. Similarly, poor load-balancing 
decisions made by routers due to sub-optimal stateless 
hash-functions can be overwritten dynamically as 

the traffic traverses the neighboring SDN switch lead¬ 
ing to better network utilization. In all three examples, 
the factor limiting the performance is the hardware de¬ 
sign itself, ie., the forwarding table organization, its 
forwarding table size, or the hash function used by the 
router. Unlike software, this cannot be improved with¬ 
out buying new equipment, hence the interest. 

In [^, Gupta et al. used a similar technique to scale 
an SDN-based Internet Exchange Point with the aim of 
decreasing the amount of forwarding rules that has to be 
maintained in the SDN switch by leveraging neighbor¬ 
ing router resources. While we target convergence, not 
space, our contribution is also the opposite of theirs. We 
show how a SDN switch can improve the performance 
of the router. As such, our work nicely complements 
theirs. 

Today’s (slow) convergence. The convergence time 
of traditional IP routers is directly linked to the time it 
takes for the router to update its hardware-based For¬ 
warding Information Base (FIB) after it detects the fail¬ 
ure. To achieve fast lookup and limit memory cost, the 
FIB only contains the information strictly necessary to 
forward packet. In the case of Ethernet interface, each 
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Eigure 2: In a supercharged router, the combined EIB 
is hierarchical, each EIB entry in the router points to 
a virtual L2 NH or pointer that is resolved in the SDN 
switch. Upon failure of i?2, only one entry —the pointer 
value—needs to update to restore full connectivity. 

EIB entry maps an IP destination to the L2 NH address 
(z.e., MAC address) of the chosen IP NH as well as the 
output interface. 

In most routers, the EIB is flat, meaning each EIB 
entry is mapped to a different (but possibly identical in 
content) L2 NH entry. As an illustration, consider the 
network depicted in Eig. R1 is an edge router con¬ 
nected to the router of two providers, R2 and i?3. Each 
of these provider routers advertise a full Internet routing 
table composed of more than 512,000 IPv4 prefixes [^. 
Also, as R2 is cheaper than i?3, R1 is configured to pre¬ 
fer R2 for all destinations. In such a case, each of the 
512k EIB entries in R1 is associated to a distinct L2 
NH entry which all contain the physical MAC address 
of i?2 (00:aa). 

Upon the failure of a i?2, every single entry of R1 EIB 
has to be updated creating a significant downtime. Our 
measurements on a recent router (see © shows that it 
actually takes several minutes for R1 to fully converge, 
during which traffic is lost. With the ever rising cost 
of downtime 10 and as services increasingly rely on 


high-availability, convergence of the order of minutes is 
simply not acceptable. 


Supercharging convergence 

a hierarchical EIB 


Equipping routers with 


II is an obvious solution to the con¬ 
vergence problem mentioned above. In a hierarchical 
EIB, each IP destination is mapped to a pointer that 
resolves to the actual L2 NH to be used. Upon failure 
of a L2 NH, only pointer values have to be updated. 
Since the number of L2 NH is several order of magni¬ 
tude smaller than the number of EIB entries, conver¬ 
gence is greatly improved. Unfortunately, hierarchical 
EIB designs also means much more complex hardware, 
and therefore, more expensive routers. 

Eig. [^illustrates how we can provide any router (here 
Rl) with a hierarchical EIB, spanning two devices, by 
combining it with a SDN switch. To provision forward¬ 
ing entries in this hierarchical EIB, we built a super- 
eharged eontroller. While the controller can rely on 
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(typically) OpenFlow to provision forwarding entries 
in a SDN switch, dynamically provisioning specific for¬ 
warding entries in a router is trickier. Our key insight 
is that the supercharged controller can use any routing 
protocol spoken by the router as a provisioning inter¬ 
face. Indeed, FIB entries in a router directs traffic to 
the L2 NH associated to the L3 NH learned via the 
routing protocol. Our supercharged controller inter¬ 
poses itself between the router and its peers (we explain 
how to make this reliable in ^ , computes primary and 
backup NH for all IP destinations, and provisions L2 
NH “pointers” by setting the IP NH field to a virtual L3 
NH that gets resolved by the router into a L2 NH us¬ 
ing ARP. Upon failure of R2 in Fig. all the controller 
has to do to convergence is to modify the switch rule 
to (rewrite(00:ff) to (02:bb,2)) in order to converge all 
traffic to R3. 

Contributions. We make the following contributions: 

• Supercharging router convergence: We propose 
novel ways to combine SDN and legacy networking 
equipment to improve convergence times (Q- 

• Implementation: We describe a fully working pro¬ 
totype implementation of a supercharger controller, 
combining OpenFlow/Floodlight and ExaBGP (^. 
Our implementation is efficient, reliable, and can be 
used to supercharge any router. 

• Hardware-based Evaluation: We supercharged a 
hardware router (Cisco Nexus 7k) and thoroughly 
evaluated its performance (@. To ensure precise 
measurements, we developed a FPGA-based traffic 
generator which detects traffic loss within TOjas. With 
respect to the normal router convergence under sim¬ 
ilar conditions, the supercharged version converged 
systematically within 150ms, a 900 x reduction! 

2. SUPERCHARGING CONVERGENCE 

In this section, we describe how to supercharge the 
convergence of any existing router using SDN equip¬ 
ment to build a hierarchical forwarding table. 

Overview. Since the number of destinations is much 
greater than the number of neighbors, many destina¬ 
tions (IP prefixes) will share the same primary and 
backup NH. We refer to the couple (primary NH, backup 
NH) as backup-group. For instance, in Fig. all 512k 
prefixes share (i?2, R3) as backup-group. If R2 fails, all 
entries will be rewritten to point to R3. 

In a supercharged router, we use the router to tag 
the traffic according to the backup-group it belongs to 
and use the switch to redirect the tagged traffic to the 
master or backup NH depending on its status. We use 
the destination MAG address as the tag and provision 
it in the router using the virtual NH field in routing 
announcements. Fig. [^depicts the overall architecture. 


Supercharged router 



peern 


Figure 3: Supercharged router overview 

Provisioning tagging entries in the router’s FIB. 

To provision entries in the router’s FIB, a routing dae¬ 
mon is interposed between the router and its peers. Its 
role is to compute the backup-groups for every IP desti¬ 
nation. For simplicity, we assume that BGP is used as 
routing protocol, but other intra-domain routing pro¬ 
tocols such as OSPF or IS-IS can also be used [^. 
The routing daemon assigns a Virtual IP NH (VNH) 
and a corresponding virtual MAG (VMAG) address to 
each distinct backup-group and rewrites the routing NH 
in the corresponding announcements that it directs to 
the supercharged router. In Fig. the backup-group 
for 1.0.0.0/24 is {peerpeern) and the corresponding 
(VNH, VMAG) is (10.1.1.1, 00:ff). Upon reception of a 
route associated with a VNH, the router issues an ARP 
request to resolve it to a MAG address. This ARP re¬ 
quest is caught by the SDN controller which replies with 
the corresponding VMAG address. After that, the su¬ 
percharged router will use the VMAG as the destination 
MAG for all the corresponding traffic sent in the data- 
plane. 

bck_groups = {} 
routing_table = {} 

def compute_backu p_grou ps(bgp_u pd): 
old = routing_table[bgp_upd.pfx] 
insert(routing_table, bgp_upd) 
new = routing_table[bgp_upd.pfx] 

if old: 
if not new: 

send_withd raw( bgp_u pd. pfx) 
else: 

if new != old: 

if len(new) == 1: 
send(bgp_upd) 
else: 

if (new[0].nh, new[l].nh) != (old[0].nh, old[l].nh): 
if new[0].nh not in bck_groups: 

bck_groups[new[0].nh] = {} 
if new[l].nh not in bck_groups[new[0].nh]: 

bck_groups[new[0].nh][new[l].nh] = get_new_vnh_vmac() 
rewrite_nh(bgp_upd, bck_groups[new[0].nh][new[l].nh].nh) 
send(bgp_upd) 

else: 

send(bgp_upd) 

Listing 1: Online algorithm computes backup-group 
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Computing backup-groups. Listing describes an 
online algorithm for computing the backup-group. In 
essence, the algorithm maintains an ordered list of known 
NH for each IP prefix with the two first elements iden¬ 
tifying the backup-group. The algorithm sends a rout¬ 
ing update with a VNH whenever one of these elements 
change. Observe that the total number of backup-groups 
depends on the number of peers n the supercharged 
router has. Taking into account all the neighbors of 
the supercharged router, the total number of backup- 
groups is \ instance, considering a router 

with 10 neighbors (a lot in practice), the number of 
backup-groups is only 90. In this paper, we worked 
with backup-group of size 2, which can protect from 
any single link or node failure. Our algorithm in gen¬ 
eral though and can compute backup-groups of any size. 

Directing tagged traffic to the appropriate NH in 
the switch’s FIB. The controller provisions dedicated 
flow entries to match on the VMAC associated to each 
backup-group. By default, these rules direct the traffic 
to the primary NH. Upon a node or a link failure, all 
the backup-group entries for which the unreachable NH 
was the primary NH are rewritten to direct the traffic to 
the backup NH instead. In the worst case, the number 
of flow rewritings that has to be done is the number of 
peers of the supercharged router, i.e. a small constant 
value. Listing [^describes how the controller determines 
what flow to install. 

def data_plane_convergence(peer_down_id): 
for backup_nh in bck_groups[peer_down_id]: 

instalLflow( 

match(dst_mac=bck_groups[peer_downJd][backup_nh].vmac), 
modify (dst_mac=get_mac(backup_nh)), 
fwd(output_port=get_port(backup_nh)) 

) 

Listing 2: Data-plane convergence procedure 


3. IMPLEMENTATION 


We now briefly describe a reliable implementation of a 
supercharged controller. All our source code is available 

at https://github.com/nsg-ethz/supercharged_router 


Controller. We built our prototype atop ExaBGP 
as BGP controller^ FreeBFD 14 as BFD daemon (fail¬ 


ure detection), and Floodlight 15 as SDN controller. 


ExaBGP enables us to establish BGP adjacencies and 
programmatically receive and send BGP routes over 
them. We extended ExaBGP with a complete imple¬ 
mentation of the BGP Decision Process, the full algo¬ 
rithm to compute backup groups (see Listingand the 
ability to rewrite BGP NH on-the-fly. FreeBFD pro¬ 
vides a user-space implementation of the Bidirectional 
Forwarding Detection Protocol (BFD) |^. We use it 
to speed up the discovery of peer failure. Upon a peer 


failure announcement produced by FreeBFD, ExaBGP 
uses the REST API provided by Floodlight to push the 
corresponding rewrite rules in the data-plane (see ©• 
We also extended Floodlight with an ARP resolver in or¬ 
der to reply to the ARP queries generated by the router 
for resolving the virtual NH to the corresponding virtual 
MAG address. 

Reliability. Any underlying SDN switch or any control- 
plane component of the supercharged controller can fail 
at any time. Since our goal is to enable fast convergence, 
our controller must be able to survive to any component 
failure to be of any use. Fortunately, reliability at both 
the data-plane and the control-plane is easily ensured. 

At the data-plane level, reliability is obtained by us¬ 
ing at least two SDN-enabled switches connected to 
each supercharged router. Observe that redundant SDN 
switches can be shared across multiple supercharged 
routers that share physical connectivity, reducing the 
costs. At the control-plane level, reliability is enforced 
by running at least 2 instances of the controller and con¬ 
necting them to the corresponding supercharged router. 
Interestingly, no state needs to be synchronized across 
the backups as both backups will receive exactly the 
same input (BGP routes) and run the exact same de¬ 
terministic algorithm and, hence, eventually compute 
the same outcome. The cost is the supercharged router 
to receive two copies of each route, and for the peers 
to configure an extra BGP session—slightly increas¬ 
ing the load in the control-plane. However, we note 
that control-plane memory is inexpensive (being classi¬ 
cal DRAM) and routers maintain multiple BGP adja¬ 
cencies already, for obvious redundancy reasons. 

4. EVALUATION 

We now present a thorough evaluation of the conver¬ 
gence time of a recent hardware router prior and after 
supercharging it using our prototype implementation. 
We then illustrate the scalability of our controller im¬ 
plementation using micro-benchmarks. 

Setup and methodology. Our complete setup is de¬ 
picted in Figj^ It consists of 3 routers Gisco Nexus 7k 
G7018 (running NX-OS v6.2, with no hierarchical FIB) 
interconnected through a HP E3800 J9575A Openflow- 
enabled switch. 

Using this setup, we measured the convergence time 
of R1 prior and after supercharging it. To do so, we 
loaded R2 and R3 with an increasing number of actual 
BGP routes collected from the RIPE RIS dataset p~7] . 
Both R2 and R3 were loaded with the same feed to en¬ 
sure that they both advertise the same set of prefixes. 
In both cases (supercharged and not supercharged), R1 
was configured to prefer R2 for all the destinations. 
Once all routes were advertised, we started to inject 
traffic at R1 using a FPGA-based generator (see below). 
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Figure 4: Overview of our HW-based convergence lab. 
R2 is rendered inaccessible, causing R1 to switch to 
R3 for every single prefixes. At the same time, we use 
FPGAs to precisely (/is resolution) measure the conver¬ 
gence time. Ultimately, we compare the convergence 
time of the supercharged R1 and the standalone Rl. 


To compute a representative distribution of the conver¬ 
gence time across different prefixes, we generated traffic 
towards 100 IP addresses, randomly selected among the 
IP prefixes advertised by R2 and R3, and including the 
first and last prefix advertised. We configured R2 and 
R3 to send all receiving traffic to another FPGA-based 
board, acting as sink. To ensure that the same de¬ 
tection time in both experiments, we configured BFD 
on R2 on both experiments. We then disconnected R2 
from the switch, triggering the convergence process at 
Rl; subsequently, we measure the time until recovering 
full connectivity. 

Custom-built hardware-based traffic generator. 

Since this project deals with/a5^ convergence, we needed 
a way to accurately measure small convergence time. 
Our choice rapidly went to hardware-based measure¬ 
ment, using FPGA boards. Using the FPGAs, we were 
able to measure convergence time with a precision of 
only 70 fis. Such a precision would be impossible to 
achieve using software-based measurements. 

We measured the convergence time by monitoring 
the maximum inter-packet delays seen by each flow be¬ 
tween two FPGA boards: a source and a sink. For 
the FPGA boards, we used a system-on-chip architec¬ 
ture with (i) embedded MicroBlaze soft processor 
(a) an Ethernet MAG core, and (hi) either a traffic 
generator (source) or traffic monitor (sink). The traf¬ 
fic monitor matches the destination IP to a content- 
addressable memory (GAM) containing the expected 
destination IPs, before it updates the corresponding 
maximum inter-packet delay. We implemented both, 
source and sink, on Xilinx ML605 evaluation boards 
featuring a Virtex-6 XG6VLX240T-1FFG1156 FPGA. 

We programmed the source FPGA to continuously 
send a stream of 64-byte UDP packets to each of the 
100 IPs over an IG Ethernet connection. Doing so gen¬ 
erated a traffic load of about 725 MBit/s, which corre- 
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Eigure 5: With respect to the normal convergence time 
which increases linearly with the number of prefixes, 
our supercharged router systematically converged within 
150ms. In contrast, the non-supercharged router took 
more than 2 minutes to converge in the worst-case. 


spends to about 1.4M packets/s in total and 14K pack¬ 
ets/s per flow. 

The non-supercharged Rl took ~2.5niin to con¬ 
verge in the worst-case. Using the methodology 
above, we measured the convergence time of the router 
prior and after the supercharging process for an increas¬ 
ing number of prefixes (from Ik to 500k). We repeated 
the experiment 3 times per number of advertised pre¬ 
fixes. Since for each experiment, we measured the con¬ 
vergence of 100 prefixes, we ended up with 300 sta¬ 
tistically representative data points per measurement. 
Eig. [^depicts the distribution of the convergence time 
using box-plots; both the non-supercharged and super¬ 
charged routers are displayed. Each box shows the 
inter-quartile range of the convergence time; the line 
in the box depicts the median value; and the whiskers 
show 5th and 95th percentiles. The numbers on top are 
the maximal convergence time recorded. 

Eor the non-supercharged Rl, we can see that the 
convergence time is roughly hnea]0 in the number of 
prefixes in the EIB. This is because EIB entries are up¬ 
dated one-by-one; while the first EIB entry is updated 
immediately, irregardless of the total number of pre¬ 
fixes, the last entry updated must wait for all the pre¬ 
ceding EIB entries to be updated. This worst-case high¬ 
lights undesirability of the non-supercharged approach: 
as the EIB grows, so does the convergence time. Here, 
we see that Rl took close than 2.5min to converge when 
loaded with 512k. 

The supercharged Rl systematically converged 
within IBOms^ for all prefixes. Thanks to its hier- 

^The linearity of convergence time is not well reflected in 
Fig. 1^ because of the non-uniform scaling of the x-axis. 
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archical FIB design, the supercharged Rl’s convergence 
time was constant—irrespective of the number of pre¬ 
fixes. This is illustrated in Fig. by a almost hori¬ 
zontal line around 150ms. With respect to the above 
worst-case, this constitutes a 900 x improvement fac¬ 
tor. Interestingly, the worst-case convergence time of a 
supercharged router is still more than two times faster 
that the best-case convergence time of its standalone 
counterpart. Indeed, in the best case, it took 375 ms 
for the standalone R1 to update the first FIB entry. 

The supercharged controller processed each BGP 
update under 125nis. While supercharging router 
drastically improves its data-plane convergence time, it 
slightly increases its control-plane convergence time due 
to the need to re-compute the backup-group upon ev¬ 
ery BGP announcement and, potentially, update the 
virtual NH. To quantify this overhead, we measured 
the time our unoptimized, python-based BGP controller 
took to process two times 500K updates from two differ¬ 
ent peers. In the worst-case, processing an update took 
0.8s but the 99th percentile was only 125ms. We argue 
that this is a reasonable price to pay for improving the 
convergence by several orders of magnitude. 


5. RELATED WORK 


Routing. The problem of minimizing down time dur¬ 
ing convergence has been well studied in the domain of 
distributed routing protocols 18 19 20 11 . Among 
all these works, BGP Prefix Independent Convergence 
(PIC) is certainly the most relevant. PIC intro¬ 
duces the idea of using a hierarchical FIB design in or¬ 
der to speed-up router convergence upon peering link 
failure. In essence, our supercharged router replicates 
the functionality of PIC but on any routers (even old 
ones), without requiring expensive line-cards update. 


SDN. FatTire 21 is a domain-specific language which 


aims at simplifying the design of fault-tolerant network 
programs that can quickly converge by leveraging fast- 
failover mechanisms provided in recent versions of Open- 
Flow [^. While FatTire targets fully-deployed Open- 
Flow networks, we show that we can already speed up 
the convergence of existing network with a single SDN 
switch. In [^, Gamperli et al. evaluated the effect of 
centralization on BGP convergence. They showed that 
the convergence time decreases as more and more of 
the network-wide decision get centralized. Supercharg¬ 
ing routers is a direct complement to their work. Once 
enough routers have been supercharged, one can use 23 


at the network-level to speed-up convergence even more. 
Just as a supercharged router, SDX is also an ex¬ 
ample of how routing and SDN can coexist in a sym¬ 
biotic way, providing each other benefit. While SDX 
showed how router can boost SDN equipment perfor¬ 
mance, we show how SDN equipment can boost router 


performance. Also, our technique can immediately be 
applied to the SDX environment in order to boost the 
convergence time upon the failure of an IXP participant 
equipment. 


Incremental SDN deployment 

Panopticon 


RouteFlow 24 and 


25 proposed techniques to incrementally 


deploy SDN equipments in existing networks with the 
aim of reaping early benefits. RouteFlow enables op¬ 
erator to build fully-fledged IP router out of a SDN 
switch, while Panopticon enables to steer traffic away 
from a L2 domain to SDN equipment where it could be 
processed. In contrast to supercharging routers, none 
of them improve the performance of existing equipment. 
In 26 , Agarwal et al proposed a way to improve the 


Traffic Engineering (TE) performance of existing net¬ 
works even in partial deployment of SDN capability, 
highlighting another aspect of the network that can be 
“supercharged” using SDN devices. 


6. CONCLUSIONS 

We boost the convergence time of legacy routers by 
combining them with SDN equipment in a novel way, es¬ 
sentially building a hierarchical forwarding table span¬ 
ning across devices. Through thorough evaluations on 
real hardware, we demonstrated significant gains with 
convergence time reduced by up to 900 x. 

We believe this paper opens up many interesting fu¬ 
ture directions for integrating legacy routing and SDN 
devices in a more “symbiotic way”. By juxtaposing the 
agility of the SDN with the tried-and-true routers preva¬ 
lent in the industry today, we take the best of both 
worlds and take the first steps towards electrifying mod¬ 
ern day networks through supercharged networking de¬ 
vices. 
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